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A Framework for Point-to-Multipoint MPLS in Transport Networks 


Abstract 


The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the 
common set of MPLS protocol functions defined to enable the 
construction and operation of packet transport networks. The MPLS-TP 
supports both point-to-point and point-to-multipoint transport paths. 
This document defines the elements and functions of the MPLS-TP 
architecture that are applicable specifically to supporting point-to- 
multipoint transport paths. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7167. 
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1 


Introduction 


The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the 
common set of MPLS protocol functions defined to meet the 
requirements specified in [RFC5654]. The MPLS-TP Framework [RFC5921] 
provides an overall introduction to the MPLS-TP and defines the 
general architecture of the Transport Profile, as well as the aspects 
specific to point-to-point transport paths. The purpose of this 
document is to define the elements and functions of the MPLS-TP 
architecture applicable specifically to supporting point-to- 
multipoint transport paths. 


.l. Scope 


This document defines the elements and functions of the MPLS-TP 
architecture related to supporting point-to-multipoint transport 
paths. The reader is referred to [RFC5921] for the aspects of the 
MPLS-TP architecture that are generic or are concerned specifically 
with point-to-point transport paths. 


.2. Terminology 
Term Definition 
CE Customer Edge 
LSP Label Switched Path 
LSR Label Switching Router 
MEG Maintenance Entity Group 
MEP Maintenance Entity Group End Point 
MIP Maintenance Entity Group Intermediate Point 


MPLS-TE MPLS Traffic Engineering 
MPLS-TP MPLS Transport Profile 


OAM Operations, Administration, and Maintenance 

OTN Optical Transport Network 

P2MP Point-to-multipoint 

PW Pseudowire 

RSVP-TE Resource Reservation Protocol - Traffic Engineering 

SDH Synchronous Digital Hierarchy 

tLDP Targeted LDP 

Detailed definitions and additional terminology may be found in 
[RFC5921] and [RFC5654]. 
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2s 


Applicability 


The point-to-multipoint connectivity provided by an MPLS-TP network 
is based on the point-to-multipoint connectivity provided by MPLS 


networks. Traffic Engineered P2MP LSP support is discussed in 
[RFC4875] and [RFC5332], and P2MP PW support is being developed based 
on [P2MP-PW-REQS] and [VPMS-FRMWK-REQS].  MPLS-TP point-to-multipoint 


connectivity is analogous to that provided by traditional transport 
technologies such as Optical Transport Network point-to-multipoint 
[G.798] and drop-and-continue [G.780], and thus supports the same 
class of traditional applications, e.g., video distribution. 


The scope of this document is limited to point-to-multipoint 
functions and it does not discuss multipoint-to-multipoint support. 


MPLS-TP P2MP Requirements 


The requirements for MPLS-TP are specified in [RFC5654], [RFC5860], 
and [RFC5951]. This section provides a brief summary of point-to- 
multipoint transport requirements as set out in those documents; the 
reader is referred to the documents themselves for the definitive and 
complete list of requirements. This summary does not include the RFC 
2119 [BCP14] conformance language used in the original documents as 
this document is not authoritative. 


From [RFC5654]: 


o MPLS-TP must support traffic-engineered point-to-multipoint 
transport paths. 


o MPLS-TP must support unidirectional point-to-multipoint transport 
paths. 


o MPLS-TP must be capable of using P2MP server (sub)layer 
capabilities as well as P2P server (sub)layer capabilities when 
supporting P2MP MPLS-TP transport paths. 


o The MPLS-TP control plane must support establishing all the 
connectivity patterns defined for the MPLS-TP data plane (i.e., 
unidirectional P2P, associated bidirectional P2P, co-routed 
bidirectional P2P, unidirectional P2MP) including configuration of 
protection functions and any associated maintenance functions. 


o Recovery techniques used for P2P and P2MP should be identical to 
simplify implementation and operation. 


o Unidirectional 1+1 and 1:n protection for P2MP connectivity must 
be supported. 
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[e] 


MPLS-TP recovery in a ring must protect unidirectional P2MP 
transport paths. 


From [RFC5860]: 


[e] 


The protocol solution(s) developed to perform the following OAM 
functions must also apply to point-to-point associated 
bidirectional LSPs, point-to-point unidirectional LSPs, and point- 
to-multipoint LSPs: 

* Continuity Check 

* Connectivity Verification, proactive 

* Lock Instruct 

* Lock Reporting 

* Alarm Reporting 

* Client Failure Indication 

* Packet Loss Measurement 

* Packet Delay Measurement 

The protocol solution(s) developed to perform the following OAM 
functions may also apply to point-to-point associated 
bidirectional LSPs, point-to-point unidirectional LSPs, and point- 
to-multipoint LSPs: 

* Connectivity Verification, on-demand 

* Route Tracing 


* Diagnostic Tests 


* Remote Defect Indication 


From [RFC5951]: 


[e] 


Frost, 


For unidirectional (P2P and point-to-multipoint (P2MP)) 
connection, proactive measurement of packet loss and loss ratio is 
required. 


For a unidirectional (P2P and P2MP) connection, on-demand 
measurement of delay measurement is required. 
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4. 


4. 


Architecture 


The overall architecture of the MPLS-TP is defined in [RFC5921]. The 
architecture for point-to-multipoint MPLS-TP comprises the following 
additional elements and functions: 


o Unidirectional point-to-multipoint LSPs 
o Unidirectional point-to-multipoint PWs 
o Optional point-to-multipoint LSP and PW control planes 


o Survivability, network management, and Operations, Administration, 
and Maintenance functions for point-to-multipoint PWs and LSPs. 


The following subsection summarises the encapsulation and forwarding 
of point-to-multipoint traffic within an MPLS-TP network, and the 
encapsulation options for delivery of traffic to and from MPLS-TP CE 
devices when the network is providing a packet transport service. 


1. MPLS-TP Encapsulation and Forwarding 


Packet encapsulation and forwarding for MPLS-TP point-to-multipoint 
LSPs is identical to that for MPLS-TE point-to-multipoint LSPs. 
MPLS-TE point-to-multipoint LSPs were introduced in [RFC4875] and the 
related data-plane behaviour was further clarified in [RFC5332]. 
MPLS-TP allows for both upstream-assigned and downstream-assigned 
labels for use with point-to-multipoint LSPs. 


Packet encapsulation and forwarding for point-to-multipoint PWs has 
been discussed within the PWE3 Working Group [P2MP-PW-ENCAPS], but 
such definition is for further study. 


Operations, Administration, and Maintenance 


The requirements for MPLS-TP OAM are specified in [RFC5860]. The 
overall OAM architecture for MPLS-TP is defined in [RFC6371], and 
P2MP OAM design considerations are described in Section 3.7 of that 
RFC. 


All the traffic sent over a P2MP transport path, including OAM 
packets generated by a MEP, is sent (multicast) from the root towards 
all the leaves, and thus may be processed by all the MIPs and MEPs 
associated with a P2MP MEG. If an OAM packet is to be processed by 
only a specific leaf, it requires information to indicate to all 
other leaves that the packet must be discarded. To address a packet 
to an intermediate node in the tree, Time-to-Live-based addressing is 
used to set the radius and additional information in the OAM payload 
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is used to identify the specific destination. It is worth noting 
that a MIP and MEP may be instantiated on a single node when it is 
both a branch and leaf node. 


P2MP paths are unidirectional; therefore, any return path to an 
originating MEP for on-demand transactions will be out of band. Out- 
of-band return paths are discussed in Section 3.8 of [RFC5921]. 


A more detailed discussion of P2MP OAM considerations can be found in 
[MPLS-TP-P2MP-OAM]. 


6. Control Plane 


The framework for the MPLS-TP control plane is provided in [RFC6373]. 
This document reviews MPLS-TP control-plane requirements as well as 
provides details on how the MPLS-TP control plane satisfies these 
requirements. Most of the requirements identified in [RFC6373] apply 
equally to P2P and P2MP transport paths. The key P2MP-specific 
control-plane requirements are: 


o requirement 6 (P2MP transport paths), 

o requirement 34 (use P2P sub-layers), 

o requirement 49 (common recovery solutions for P2P and P2MP), 
o requirement 59 (1+1 protection), 

o requirement 62 (1:n protection), and 

o requirement 65 (1:n shared mesh recovery). 


[RFC6373] defines the control-plane approach used to support MPLS-TP 
transport paths. It identifies GMPLS as the control plane for MPLS- 
TP LSPs and tLDP as the control plane for PWs.  MPLS-TP allows that 

either, or both, LSPs and PWs to be provisioned statically or via a 

control plane. Quoting from [RFC6373]: 


The PW and LSP control planes, collectively, must satisfy the 
MPLS-TP control-plane requirements. As with P2P services, when 
P2MP client services are provided directly via LSPs, all 
requirements must be satisfied by the LSP control plane. When 
client services are provided via PWs, the PW and LSP control 
planes can operate in combination, and some functions may be 
satisfied via the PW control plane while others are provided to 
PWs by the LSP control plane. This is particularly noteworthy for 
P2MP recovery. 


Frost, et al. Informational [Page 7] 


RFC 7167 MPLS Transport Profile P2MP Framework April 2014 


6.1. P2MP LSP Control Plane 


The MPLS-TP control plane for P2MP LSPs uses GMPLS and is based on 


RSVP-TE for P2MP LSPs as defined in [RFC4875]. A detailed listing of 
how GMPLS satisfies MPLS-TP control-plane requirements is provided in 
[RFC6373]. 


[RFC6373] notes that recovery techniques for traffic engineered P2MP 
LSPs are not formally defined, and that such a definition is needed. 
A formal definition will be based on existing RFCs and may not 
require any new protocol mechanisms but, nonetheless, should be 
documented. GMPLS recovery is defined in [RFC4872] and [RFC4873]. 
Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3. 


6.2. P2MP PW Control Plane 


The MPLS-TP control plane for P2MP PWs should be based on the LDP 
control protocol used for point-to-point PWs [RFC4447], with updates 
as required for P2MP applications. A detailed specification of the 
control plane for P2MP PWs is for further study. 


7. Survivability 


The overall survivability architecture for MPLS-TP is defined in 
[RFC6372], and Section 4.7.3 of that RFC in particular describes the 
application of linear protection to unidirectional P2MP entities 
using 1*1 and 1:1 protection architecture. For 1+1, the approach is 
for the root of the P2MP tree to bridge the user traffic to both the 
working and protection entities. Each sink/leaf MPLS-TP node selects 
the traffic from one entity according to some predetermined criteria. 
For 1:1, the source/root MPLS-TP node needs to identify the existence 
of a fault condition impacting delivery to any of the leaves. Fault 
notification happens from the node identifying the fault to the root 
node via an out-of-band path. The root then selects the protection 
transport path for traffic transfer. More sophisticated 
survivability approaches such as partial tree protection and 1:n 
protection are for further study. 


The IETF has no experience with P2MP PW survivability as yet; 
therefore, it is proposed that the P2MP PW survivability will 
initially rely on the LSP survivability. Further work is needed on 
this subject, particularly if a requirement emerges to provide 
survivability for P2MP PWs in an MPLS-TP context. 
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8. 


10. 


10. 


Network Management 


An overview of network management considerations for MPLS-TP can be 
found in Section 3.14 of [RFC5921]. The provided description applies 
equally to P2MP transport paths. 


The network management architecture and requirements for MPLS-TP are 
specified in [RFC5951]. They derive from the generic specifications 
described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. 
They also incorporate the OAM requirements for MPLS networks 
[RFC4377] and MPLS-TP networks [RFC5860] and expand on those 
requirements to cover the modifications necessary for fault, 
configuration, performance, and security in a transport network. 
[RFC5951] covers all MPLS-TP connection types, including P2MP. 


[RFC6639] provides the MIB-based architecture for MPLS-TP. It 
reviews the interrelationships between different MIB modules that are 
not MPLS-TP specific and that can be leveraged for MPLS-TP network 
management, and identifies areas where additional MIB modules are 
required. While the document does not consider P2MP transport paths, 
it does provide a foundation for an analysis of areas where MIB- 
module modification and addition may be needed to fully support P2MP 
transport paths. There has also been work in the MPLS working group 
on a P2MP specific MIB, [MPLS-TE-P2MP-MIB]. 


Security Considerations 


General security considerations for MPLS-TP are covered in [RFC5921]. 
Additional security considerations for P2MP LSPs are provided in 
[RFC4875]. This document introduces no new security considerations 
beyond those covered in those documents. 
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